Essay/Term paper: Databases and y2k

Essay, term paper, research paper:  College Papers

Databases and the Impact of the Approaching Millenium.

Introduction: Tremendous problems loom just around the corner for
organizations that use two-digit years (i.e. 1-9-97). How tough could
it be to change the year from 1999 to 2000? The "Year 2000 Problem"
cannot be fixed by simply resetting a computer's internal clock on
January 1, 2000. Computers may be smart, but their programmers weren't
very farsighted. In the '60s and '70s, many businesses were looking to
cut costs and because computer storage space was expensive at the time,
programmers decided to cut year dates to two digits (i.e., 1969 became
69). It doesn't sound like a major error, but computers are extremely
date-sensitive. Computers routinely add and subtract digits in a date
to make a variety of logical calculations, ranging from travel
reservations to how much interest one has accrued on a savings
account. The problem lies in the fact that many computers designate
century data using only two digits, 00, and will read 2000 as 1900.
And the bug affects more than just computer systems. Many manufacturers
have built products with software instructions embedded onto chips;
equipment ranging from fax machines to auto assembly lines could all be
affected by the bug.

What's the Problem? For many organizations, the Year 2000 Problem has
become the most complex project management exercise ever undertaken.
The reasons for this are multi-factored. For starters, we are less
than 13 months away from Year 2000 yet many organizations are just now
paying attention to it.1 There is no way to avoid the fact that our
information systems are based on a faulty standard that will cost the
worldwide computer community billions of dollars in programming effort.
This 'bug' touches on all areas of an organization, and the complexity
of analyzing and quantifying the scope of the problem, repairing and
replacing infected items, conducting adequate testing activities and
finally, implementing multiple interrelated hardware, systems and
software can be overwhelming. Compounding the difficulty is the lack of
awareness in general regarding the potential risks, and the fact that
the project is driven by a series of hard dates. In addition, many
organizations have further complicated the process by beginning their e

Databases and Y2K How might Y2K affect databases that, in turn, affect
our everyday lives? Let's take your bank account. As the 1999 turns
over to 2000, your bank's computer may calculate that your account
deserves an additional 100 year's interest. Of course, it's also
possible you may be penalized for being 100 years overdue on your loan
payment! Or suppose you have some data records and want to sort them by
date (e.g., 1965, 1905, 1966), the resulting sequence would be 1905,
1965, 1966. However, if you add in a date record such as 2015, the
computer, which reads only the last two digits of the date, sees 05,
15, 65, 66, and sorts them incorrectly.2 Or you are running a little
late for your airline flight, but your reservation seems to have been
cancelled 100 years ago. Unchecked, database glitches as a result of
Y2K could be endless.

Some databases will appear to not have Year 2000 problems
because they convert a given day, month and year to a single
number. That number is equal to the total number of days since
a certain date earlier in time, for instance - 1-11900. In
other words, it calculates the actual number of days (i.e.
"35,405") since that earlier date in time. Nonetheless, Year
2000 problems could arise if a 2-digit year in historical date
is electronically transferred into the system after Jan. 1,
1000. Electronic transfers must use a program with the same
assumptions!3 Thus, the same problems could arise.

Solutions The two primary approaches to remedying the problem are to
expand the date fields to four digits or to add code that looks at
those two existing digits and appends the proper century. To do this,
code writers must first find all the dates, which could be difficult
because of unconventional date coding by programmers. The coders must
then identify all instances in which an organization or corporation
exchanges data electronically. Unless both exchanging parties are
"2000-compliant," either could become easily contaminated by the
non-compliant system. These changes don't come cheap. The consulting
firm Gartner Group estimates up to $600 billion will be spent worldwide
to rewrite 250 billion lines of code.4 Even more daunting is the
testing of these changes, which could be the most time-consuming part
of the process.


Numerous software companies have attempted to address the Y2K
problem with the development of transition software. Serious
Software, Ltd. has officially released ACC-FIX 2000TM, a new
remediation tool that actually automates the process of
correcting (instead of simply reporting on) Year 2000 problems
in Microsoft(r) Access desktop databases.5

Conclusion The Y2K problem is solvable, but time is running out. The
Y2K problem needs to be the number one priority of government and
organizations, and efforts must be made to raise awareness of the scope
and risk of the Y2K. To avoid the "Doomsday 2000" that Peter DeJager
wrote about in his now infamous article from the September 6, 1993
issue of ComputerWorld, it is imperative that corporate and government
executive management demand the right people, tools and approach. What
was originally a 'bug' has become a crisis. The clock is ticking.

Works Cited
(Listed in order of importance)


Cox, Don. "Effective Project Management for the Year 2000," Year 2000 and the
Computer.

DeJager, Peter. "Doomsday 2000," ComputerWorld, Sept. 6, 1993.

Dorn, Mark. National Underwriter/Life & Health Financial Services, Vol. 102 Issue 24,
p7, 3p. June 15, 1998.

Piazza, Ethna. San Diego Business Journal, Vol. 18, Issue 9, p39, 3/3/97.

Y2K Wire, November 10, 1998.


1 Dorn, Mark. National Underwriter/Life & Health Financial Services, Vol. 102 Issue 24, p7, 3p. June 15, 1998.
2 DeJager, Peter. "Doomsday 2000," ComputerWorld, Sept. 6, 1993.
3 Piazza, Ethna. San Diego Business Journal, Vol. 18, Issue 9, p39, 3/3/97.
4 Cox, Don. "Effective Project Management for the Year 2000," Year 2000 and the Computer.
5 Y2K Wire, November 10, 1998.